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FIELD OF THE INVENTION 

The invention relates generally to methods and apparatus of transporting audio 
and video data. More particularly, the invention relates to systems for receiving, routing 
^.5 and administering audio and video data in an access server. 


BACKGROUND OF THE INVENTION 
i]A ^ Over the past several years access servers (also referred to as communication 

e servers or terminal servers) have been used to receive data communications and to 
20 route data from remote locations onto neworks such as the Internet. For example, 
Internet Server Providers (ISPs) typically use access servers to administer data 
communications from ISP subscribers. In such implementations, the ISP typically 
configures one or more access servers in connection with modems, which are 
connected to phone lines. ISP/customers, who maintain their own computers with 
25 modems, establish a connec/on to the ISP by placing an ordinary telephone call from 
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their home modem to the ISP modem. The ISP'modem provides data to the access 
server, which typically authenticates the user and facilitates a connection from the users 
PC to the Internet across the modenvw-modem telephone connection. Such systems 
may also be used to access, for example, corporate intranets or the like. 
(fi/M 5 Recent advances in access server hardware^allowed the access server to 

support not only modem connections, butalso fax, video conference, voice, multimedia, 
Asynchronous Transfer Mode (ATM), frame relay, and other types of connections. 
Such systems frequently include dafta communications processors such as the Any Port 
Products available from Conexant Systems of Newport Beach, California. 

It is typically relatively easy to build administration systems for modem 
connections because many popular operating systems include modem control 
J functionality. The Windows NT operating system available from the Microsoft 

Corporation of Redmond, Washington, for example, includes the Telephony Application 
Programming Interface (TAPI), which includes specific interface calls for interacting 
%5 between computer applications running on the operating system and a modem. 
Similarly, Linux and other versions of UNIX typically include device drivers or 
Application Programming Interfaces (APIs) for interacting with modems. Such 
functionality is not, however, generally provided for non-modem telephone connections 
and the like. Thus, it is more difficult to create applications that make use of the voice 
20 functionality included with access server hardware, since such functionality is not 
automatically addressable within the operating system. 
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One solution to this problem is to incorporate support for voice services within 
the operating system itself. Incorporating direct operating system support is typically 
quite difficult, however, because operating systems are generally created by entities 
other than those who create access servers and access server components. Most 
5 conventional operating systems therefore do not support the wide range of access 
servers and access server components that are available. Moreover, operating system 
solutions tend to be based upon proprietary protocols, APIs or hardware, and they are 
frequently slow to react to changes in access servers or access server components. 
Another option is to develop a device drive/that is unique for the particular 
iko access server or access server components utilized. Again, however, this approach 
J provides a proprietary solution that is unique to the particular application or hardware 
J! device included. Such systems are slow to^ncorporate new functionality in operating 
I" systems or hardware, and moreover, they do not facilitate direct addressability from the 
OS external host. Direct accessibility is particularly desirable in environments with 

9 / tfiH* 

(p 5l5 distributed gateways for routing voice and data communications. Hence.^he "gateway 
^ decomposition" schemes currently/pursued many systems providers typically require 
proprietary device drivers or APIs for interacting with particular hardware. 
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Although voice-over-network solutions such as those described above are 
presently in existence, numerous problems remain with universal compatibility and 
external administration. It is therefore desired to create a system for providing voice 
services over data networks (such as the Internet) that is portable across different 
operating systems and types of access hardware. It is also desired to create a system 
that is usable with distributed gateways. 
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SUMMARY OF THE INVENTION 

In accordance with one embodiment of the present invention, a dataport in an * 
access server is suitably configured to emulate a modem connection for non-modem 
calls such as voice calls. Computer applications for administering, for example, voice- 
over-network services thus communicate with the port via standard modem calls. In 
accordance with one aspect of the invention, communications between the port 
hardware and the voice enabled application take place through an encapsulating 
protocol such as the Point-to-Point-Protocol (PPP) such that the port is addressable 
and able to receive controls or other instructions from a voice application residing on 
the access server or from a distributed location. 
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BRIEF DESCRIPTION OF THE DRAWING FIGURE 

The above and other features and advantages of the present invention are 
hereinafter described in the following detailed description of illustrative embodiments to 
be read in conjunction with the accompanying drawing figures, wherein like reference 
numerals are used to identify the same or similar parts in the similar views, and: 

Figure 1 is a block diagram of an exemplary embodiment of an access server 
system; 

Figure 2 is a block diagram of a second exemplary embodiment of an access 
server system; 

Figure 3 is a block diagram of an exemplary voice module; and 
Figure 4 is a block diagram of an exemplary communications system. 
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DETAILED DESCRIPTION OF PREFERRED EXEMPLARY EMBODIMENTS 

The present invention may be described herein in terms of functional block 
components and various processing steps. It should be appreciated that such 
functional blocks may be realized by any number of hardware and/or software 
components configured to perform the specified functions. For example, the present 
invention may employ various integrated circuit components, e.g., memory elements, 
digital signal processing elements, logic elements, look-up tables, and the like, which 
may carry out a variety of functions under the control of one or more microprocessors or 
other control devices. Further, it should be noted that the present invention may 
employ any number of conventional techniques for data transmission, signaling, data 
processing, network control, application development, and the like. Such general 
techniques are not described in detail herein. 

To simplify the description of the exemplary embodiments, the invention is 
frequently described as pertaining to a system of providing voice-over network 
J 5 functionality. It will be appreciated, however, that many applications of the present 
invention could be formulated. For example, the present invention could be used to 
transport fax data, motion picture data, closed circuit video information, multimedia 
content, photographic, stereoscopic, holographic or any other form of moving video, still 
images, data or other information.. Similarly, although the invention is frequently 
20 described herein as being implemented with TCP/IP communications protocols, it will 
be readily understood that the invention could also be implemented using IPX, 
Appletalk, IP-3, OSI or any number of existing or future protocols. 
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It should be appreciated that the particular implementations shown and 
described herein are illustrative of the invention and its best mode arid are not intended 
to otherwise limit the scope of the present invention in any way. Indeed, for the sake of 
brevity, conventional data networking, application development and other functional 
aspects of the systems (and components of the individual operating components of the 
systems) may not be described in detail herein. Furthermore, the connecting lines 
shown in the various figures contained herein are intended to represent exemplary 
functional relationships and/or physical couplings between the various elements. It 
should be noted that many alternative or additional functional relationships or physical 
connections may be present in a practical access server system. 

£ j 

v With reference to Figure 1, an access server sy/tem 100 suitable for ISDN or 

modem communications suitably includes a communications interface 104, access 

/ w\ 
hardware 120, and a computer host 140. The communications interface's any 

interface device that suitably receives call information from a network 102 such as the 

public switched telephone network (PSTNVand provides the call information via a bus 

106 to an access device. The access device may be implemented, for example, as 

access hardware 1 20, as a modem Cnot shown), or as an ISDN modem 114. In 

various embodiments of the inversion, communications interface 104 is a T1 interface, 

a modem, or another form of c/mmunications service unit (CSU). 

Bus 106 is any form of connection device such as an ethernet, token ring, 

computer bus, or the like that is capable of transferring data from interface 104 to 
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access hardware 120. In various embodiments, bus 106 is a time-division multiplexing 
(TDM) bus. In such embodiments, various forms of digital data such as high-level data 
link control (HDLC) protocol information and pulse code modulation (PCM) data are 
suitably shared by bus 106. In the exemplary embodiment shown in Figure 1, bus 106 
provides HDLC data to ISDN modem 1 14 and to an ISDN module 1 18 via interfaces 
112 and 108, respectively. Similarly, bus 106 provides PCM data to a modem module 
1 16 via an interface 110. 

Access hardware 120 is any device that includes hardware and/or software 
controls for interfacing and processing data from remote locations. In various 
embodiments, access hardware 120 includes a semiconductor device such as one or 
=t more of the Any Port processors available from Conexant Systems, Inc. of Newport 

J Beach/California. Access hardware 120 suitably includes modules for handling various 

f y 

5 _ types of data connections. Each module includes programming (such as hardware, 

i s 

top 

5 software or firmware programming) that implements a particular type of data 

\n 

Jl5 connection. Modules 1 1 6 and 1 1 8 in Figure 1 , for example, correspond to modem and 
ISDN connections, respectively. Of course, it will be recognized that the modules 
discussed herein are not necessarily physically separate, but rather- are logical 
constructs that aid in understanding. Other modules (not shown) may include voice, 
asynchronous transfer mode (ATM), frame relay, internet protocol (IP), fax, wireless 
20 and the like. 

£ ^ 'Communications may be suitably controjfed by/f an application program 134 

running on host 140. Exemplary computer applications include Remote Access Server 
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(RAS) available from the Microsoft Corporation of Redmond, Washington or the pppd 
("PPP daemon") included with variousversions of the LINUX or UNIX operating 
systems. In such embodiments, application program 134 suitably receives requests for 
network services, responds to/such requests by establishing connections, and assigns 
5 a network address (such as an IP address) to the connection established. Some 

embodiments of application program 134 further provide authentication or other security 
services. Of course 7 , it will be understood that application program 134 may be any 
suitable communications server or controller program, and that the particular 
functionality/and implementation of application program 134 will vary from embodiment 
^ho to embodiment. 


u 


Host 140 is any form of computer such as a personal computer, a minicomputer, 

J a mainframe or a specialized computer such as are available from vendors such as 

ry 

a Cisco Systems of San Jose, California. It will be understood that the invention may be 

9 implemented in any form of hardware or software environment. In various exemplary 

y 

.*15 embodiments, host 140 suitably runs an operating system 138 such as Windows 95, 
2000, or NT available from the Microsoft Corporation of Redmond, Washington. In 
alternate embodiments, host 140 runs one of the many versions of the LINUX or UNIX 
operating systems available from vendors such as Hewlett Packard of Palo Alto, 
California, IBM Corp. of Armonk, New York, or Sun Microsystems of Mountain View 
20 California. 

Operating system 138 suitably administers interactions between application 
program 134 and hardware coupled to host 140. For example, host 140 may include a 
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network interface 124 to a data network 126 such as the Internet, a corporate intranet, 

or another data network. Similarly, host 140 may include a device driver 1 22 that 

handles instructions and data transfers between application program 134 and access 

hardware 1 20. Such a device driver is typically related to the particular form of access 

hardware 120 utilized and will vary from implementation to implementation. 
A. 

VApplications such as application program 1 ^running on a host frequently 

interact with device drivers through an intermediate application programming interface 

M / 

(API) that provides a particular type of functionality depending upon the particular 

A m • / 

device driver. I ntcrf a oo .136, for example, may be a telephony application interface 

/ 

(TAPI) such as TAPI 2.1 included wjfri Microsoft Windows NT version 4.0. Telephony 
API 136 suitably implements many common functions required by application program 
134 related to telephony sucli as modem controls, ISDN controls, and the like. To 
control a modem via application 134, for example, a programmer suitably includes 
computer instructionsnn application 134 that interact via interface 146 with telephony 
AP1 136 to contro/device driver 122, which in turn interacts with access hardware 120 

and/or ISDN d/vice 114. 
•7 

Similarly, application program 134 interacts ^ith a network interface 124 via 
network AP1 130 such as, for example, the NDI9; 4.2 API provided with the Microsoft 
Windows NT operating system. Various embodiments of the network AP1 130 suitably 
include a protocol stack 132 that implements a particular suite of communications 
protocols such as TCP/IP, IPX, or the likfe. Applications 134 do not typically interact 
directly with network interface 124,itow», but rather include calls to network AP1 130 via 
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interface 144. Network ia torfooo^ l 30 then suitably formats data packets in accord with 
a protocol suite 132 and provides the packets to^nterface 124 for transmission on 

network 126. 
A* 

v As described above, application program 134 interacts with access hardware 
120 and network interface 124 via device drivers 122/and 124 and via APIs 136 and 
1 30, respectively. An illustrative example will show how the various elements of an 
exemplary embodiment work together to implement an access server system 100. 
When a call is received at telephony interface/104, for example, PCM data is suitably 
transmitted via bus 106 to the access hardware 120. A processor in access hardware 
120 recognizes the incoming call as a modem call, 'for example, and modem module 



116 places a request to an administering application (which may be application program \ 


Qccetf Sextet/ sp+ea\ 
134) to create a modem session witn the ^orvor 10 0. Modem module 1 1 6 sends a 

request for a new connection via device driver 122, which forwards the request to 

application program 134 through/telephony AP1 136. The application program 134 

receives the request and administers the new session with the access hardware 120, 

again by sending command^ and gathering data via telephony AP1 136. 

In a common access server for use in providing Internet access, for example, 

application program 134 prompts the user to enter an authorization credential such as a 

userid/password pair. Authentication information (which is typically in point-to-point 

protocol (PPP) format) is entered by the user and suitably passed via device driver 122 

to a PPP handler 128 associated with network AP1 130 for authentication. If 

authentication is successful, application program 134 proceeds to create a virtual 
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connection 148 between module 116 and the network interface 124 such that the 

remote user is allowed to access network 126. Various embodiments of application 

program 134 suitably allow multiple connections through access hardware 120, and 

each connection may be individually addressable through, for example, conventional 

socket programming techniques. In such embodiments, each connection is 

represented to application program 134 as an individually-addressable port on access 

hardware 120, each port having its own network address (such as an IP address). 

Because application program 134 assigns each port a unique network address, the port 

itself is addressable by hosts on network 126. Thus, a remote user is provided with 

direct, addressable access to network 126. 
(P 

Vas noted above, exemplary embodiments>of telephony AP1 136 contain 
adequate controls for interacting with modems and modem modules such as module 

1 16 on access hardware 120. As sucllf modem connections are relatively easy to 

0/6e55 Sen/e? $ys4evn V*> / 
implement in^egs-s orvor 10Q. /Telephony AP1 136 does not, however, typically 

contain controls for accessirj^voice modules in access hardware 120. 

Referring now to Figure 2, an access server system 200 for use in administering 

voice-over-network connections suitably includes access hardware 220 with a voice 

module 202. As described above, access hardware 220 may be any device that 

includes hardware and/or software controls for interfacing and processing data from 

remote locations such as one or more Any Port processors available from Conexant 

Systems Inc. of Newport Beach, California. Access hardware 220 may receive voice, 

ISDN, modem, and other data calls from interface 104 via bus 106, as described above. 
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ff/i A Access hardware 220 communicates with host computec/140 through device 

driver 222, which is similar to device driver 122 described above but includes added 
(Xt support for voice module 202.^B«vef 222 provides an ipferface between access 

hardware 220 and host 140 through, for example, conventional interfac e technique s. 
5 Although Figure 2 shows device driver 222 as oart of host 140, it should be noted that 
device driver 222 functionality may be suitably implemented as software on host 140 or 
in hardware, software or firmware of access hardware 220. Alternatively, device driver 
222 can be implemented as any combination of hardware, software and firmware on 
access hardware 220 and/or host 140. Various embodiments of the invention 

q / 

*£l0 implement device driver 222 as /windows NT miniport or as a LINUX or UNIX device 

J driver although of course any suitable hardware or software interface could be used. 
ifft fr Vm various embodiments of the invention, voice/module 202 is represented to 

b host 140 as a modem connection. Various embodiments implement the modem-like 

J connection differently, but exemplary techniquesMnclude formulating a modem 

y J 

%\5 connection in device driver 222 such that operating system 138 "thinks" that data 

• ^ / 

~ sessions with voice module 202 are modernf connections instead of voice connections 
To this end, device driver 222 suitably presents voice module 202 to host 140 as a 
modem port. In various embodiments/of the invention, the modem conne ction is 
established by passing an electronic/message to telephony A P1 136 with modem 
20 parameters instead of coh^njfonal voice parameters. These parameters are dictated 
by the particular telephony API, and vary from implementation to implementation. 

frj When a connection is initiated^ this manner, telephony APLsuitably creates a 
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connection with device driver 222 tha/ emulates a virtual modem connection 230 
between voice module 202 and^elephony AP1 136. 

Because the voice connection is presented to the host as a modem connection, 
the modem functionality implemented in telephony AP1 136 may be suitably used to 
5 send commands and to retrieve data between voice-enabled application 134 and voice 
module 202 though virtual connection 230. In various embodiments of the invention, 
telephony API notifies application program 134 that a modem connection is received, 
and application program 134 may then create virtual connection 148 between voice 
module 202 and network interface 124, for example as described above. Connection 

Q 

fto 148 may be created, for example, through conventional programming techniques 

utilizing the standard telephony AP1 1 36. 

I^G A Senfer 

0" jjjH "With continued reference to Figure 2, voice- access^system 200 suitably 

: 5.5 • . i 

s administers voice calls by providing a convenient interface between application program 


y 


134 and voice module 202 such that voice data/s effectively transported to network 


.if 15 126. When voice service is initiated (for example at startup, or as directed by 


application program 134, or in response to^ voice call received from network 102), 


6j module 202 establishes a virtuafmodem Connection 230 through driver 222 and 

operating system 138 to application program 134. Because the virtual connection 230 
acts as a modem connection, application program 134 communicates to device driver 
20 222 through conventional telephony API calls. These calls are suitably addressed to 
(h jdriver 222, which converts instructions and data to a format that is understood by 

fa ^module 202 as necessary. In thfe manner, application program 134 suitably interacts 
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via telephony AP1 136 and network API 130 to create virtual connection 148 between 
access hardware 220 and network 126 usincfffor example, techniques similar to those 
employed to create the virtual modem connections described above. In various 
embodiments, application prograrn^34 assigns a network address (such as an IP 
5 address) to the connection sucrnhat virtual connection 148 (and thus the port on 
access server 220 corresponding to voice module 202) is addressable by entities on 
network 126. With thyvirtual connection established, voice communications are 
suitably routed between server 220 and network 126. Thus, a standard computer 
application 134such as RAS or pppd can be used in conjunction with a standard 
SlO telephony AP1 1 36 to implement an access server system 200 that provides voice 
functionality. 

In various embodiments of the invention, voice module 202 suitably 

encapsulates voice data into a protocol frame such as a PPP header that can be 

Q 

m transmitted to a local or remote server. Alternatively, commands from a local or remote 

B 

»?15 server may be suitably encapsulated in a network frame such as a PPP frame. Voice 
* module 202 suitably extracts command information from the network frame and 
executes the commands as necessary. 

With reference to Figure 3, an exemplary voice module 202 suitably includes 
sub-modules for processing voice calls received from connection 204 to bus 106 (not 
20 shown in Figure 3). Each of the sub-modules is a logical construct that illustrates a 
particular process executed by access hardware 202. Layer 302 receives voice 
information in, for example, PCM format and decodes the data at a signaling level. As 
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such, layer 302 typically implements protocols such as G.165 and G.168, or any other 
signaling protocols required. Layer 304 administers any necessary compression or 
decompression of voice data, for example using the G.723, G.729, G.71 1 or any other 
compression routine. Layers 306, 308 and 310 suitably administer the real-time 
5 transport protocol (RTP), the user datagram protocol (UDP) and PPP, respectively. 
RTP layer 306 packages voice samples into a known format as appropriate, and UDP 
layer 308 suitably encapsulates voice data in a UDP packet that can be transmitted via 
virtual connection 148, for example, to network 126. In various embodiments, PPP 
layer 310 suitably encapsulates the voice data in a PPP frame, as described above. 
Sko Again, alternate embodiments of the invention implement voice data processing in 


different manners using various protocols. In particular, it is not necessary to include 
RTP or PPP encapsulation in all embodiments of the invention. Alternatively, the point- 
to-point tunneling protocol (PPTP) or another protocol could be substituted for PPP or 


f suitably processed as required by the particular embodiment. In various embodiments, 
application program 134 suitably routes voice data to a proper destination on network 
126 by embedding the formatted voice data in a network frame such as a TCP/IP frame 
via network AP1 130. Various embodiments of application program 134 implement 

20 signaling and routing through calls to network AP1 130. Voice data may be routed 
directly to a destination oh the network, or they may be routed to an administrative 
server on network 126 that handles routing, billing, etc. 
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Voice data produced at voice module 202 is provided to a destination and 


With reference to Figure 4, a system implementing a so-called "gateway 
decomposition" scheme includes host 140 communicating with access hardware 220 
and with data network 126. Voice calls are received from PSTN network 102 and 
routed to data network 126 through virtual connection 148 (not shown in Figure 4) as 
5 described above. Server 404 on network 126 suitably interacts with voice module 202 
on access hardware 220 via the network address assigned to the virtual connection to 
transmit voice data to a destination host 406. Server 404 may also provide billing, 
routing and other functionality as required. Various voice servers 404 such as those 
available from various manufacturers suitably communicate with voice module 202 via 
So network packets sent through data network 1 26. In exemplary embodiments the control 

I _ : 

^ network packets include commands that are encapsulated in PPP or other network 

i .5 

^ frames, and then sent to host 140 via, for example, conventional TCP/IP addressing 


I " and delivery techniques. With momentary reference again to Figure 2, host 140 

i receives the control packet on interface 124 and passes the data via network API 130 

o 

^15 as directed by application 134 and in accordance with addressing information contained 


1 in the control packet. In various embodiments, the control packet includes a reference 
to a particular address or socket corresponding to virtual connection 148, and the 
control packet is suitably formatted and provided to voice module 202 as described 
above! Voice module then extracts the command information from the PPP frame 

20 using layer 310 (best shown in Figure 3) and executes the command. Various 

commands instruct the voice module to produce a dial tone, hang up the line, provide 
data to a given destination, and the like. In various embodiments, voice module 202 
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further includes routing capability for administering multiple incoming voice calls through 
virtual connection 148. In this manner, many simultaneous voice connections can be 
produced through a single access hardware unit 220. 

The corresponding structures, materials, acts and equivalents of all elements in 
the claims below are intended to include any structure, material or acts for performing 
the functions in combination with other claimed elements as specifically claimed. The 
scope of the invention should be determined by the appended claims and their legal 
equivalents, rather than by the examples given above. 
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